It's just a resubmission of #5391 to workaround the GH actions problems when contributor is outside of the or

Changes

Closes #5183, Fixes #5712

Fixes permanent permissions drift when user_name casing in databricks_permissions access_control blocks differs from the API response.

Problem: The Databricks API normalizes user emails to lowercase (e.g. config has User@Example.com, API returns user@example.com). Because emails are case-insensitive, both refer to the same user, but Terraform treats them as different entries, causing a remove/re-add diff on every plan that never converges.

Fix: Normalize user_name and service_principal_name to lowercase throughout the permissions resource so that casing differences between config and API are ignored. The fix touches three areas:

1. Hash function: Lowercase user_name and service_principal_name before hashing so config and API values produce the same hash.
2. API response handling: Lowercase user_name and service_principal_name when reading the API response into state.
3. Current-user comparison: Use case-insensitive comparison (strings.EqualFold) when checking if the current user is in the config. Without this, the provider silently dropped the current user's permissions from state when their email casing differed, a second source of drift.

Detailed Changes

Hash function case normalization (permissions/resource_permissions.go, lines 191-217)

Before:

if strVal, ok := val.(string); ok {
    if strVal != "" {
        normalized[key] = strVal
    }
}

After:

if strVal, ok := val.(string); ok {
    if strVal != "" {
        if key == "user_name" || key == "service_principal_name" {
            strVal = strings.ToLower(strVal)
        }
        normalized[key] = strVal
    }
}

Why: The access_control block uses schema.TypeSet, which relies on a hash function to determine element identity. If the user's config has User@Example.com and the API returns user@example.com, they produced different hashes, so Terraform saw them as two different set elements: one to remove and one to add. Lowercasing before hashing ensures both values produce the same hash.

API response lowercasing (permissions/permission_definitions.go, lines 247-248)

Before:

entity.AccessControlList = append(entity.AccessControlList, iam.AccessControlRequest{
    GroupName:            accessControl.GroupName,
    UserName:             accessControl.UserName,
    ServicePrincipalName: accessControl.ServicePrincipalName,
    PermissionLevel:      permission.PermissionLevel,
})

After:

entity.AccessControlList = append(entity.AccessControlList, iam.AccessControlRequest{
    GroupName:            accessControl.GroupName,
    UserName:             strings.ToLower(accessControl.UserName),
    ServicePrincipalName: strings.ToLower(accessControl.ServicePrincipalName),
    PermissionLevel:      permission.PermissionLevel,
})

Why: Even with matching hashes, if the stored string value in state differs from the config value, Terraform detects a diff. Lowercasing the API response ensures the state value matches a lowercase config value.

Case-insensitive current-user comparison (permissions/permission_definitions.go, line 231)

Before:

if me == accessControl.UserName || me == accessControl.ServicePrincipalName {

After:

if strings.EqualFold(me, accessControl.UserName) || strings.EqualFold(me, accessControl.ServicePrincipalName) {

Why: == is case-sensitive, so "Admin@Example.com" == "admin@example.com" returns false. strings.EqualFold compares strings case-insensitively, correctly matching the same user regardless of casing.

Case-insensitive lookup in ContainsUserOrServicePrincipal (permissions/entity/permissions_entity.go, line 17)

Before:

if ac.UserName == name || ac.ServicePrincipalName == name {

After:

if strings.EqualFold(ac.UserName, name) || strings.EqualFold(ac.ServicePrincipalName, name) {

Why: Same as above. == is case-sensitive, so "Admin@Example.com" == "admin@example.com" returns false. strings.EqualFold compares strings case-insensitively, correctly matching the same user regardless of casing.

Tests

• TestPermissionsDrift_UserNameNoDriftWithSameCasing: Simulates an existing resource in state with user_name="user@example.com", then performs a Read where the API returns the same casing. Constructs a full InstanceState with computed set hashes and verifies that the Read produces exactly 2 access_control entries (no drift).

• TestPermissionsDrift_UserNameNoDriftWithDifferentCasing: Simulates the exact drift from issue [ISSUE] Issue with databricks_permissions resource when user_name is used for access_control. There is a permanent drift with each terraform plan and apply #5183: InstanceState has user_name="user@example.com" but the API returns User@Example.com. Verifies that after the fix, the Read normalizes the casing so that:

  1. The access_control set still has exactly 2 entries (not 3, which would indicate drift)
  2. The user_name value in state is "user@example.com" (lowercase)

Both tests use MockWorkspaceClientFunc with mocked CurrentUser.Me() and Permissions.Get() responses, and construct realistic InstanceState maps with pre-computed set hashes to simulate the post-apply state that Terraform would produce.

• make test run locally
• relevant change in docs/ folder
• covered with integration tests in internal/acceptance
• using Go SDK
• using TF Plugin Framework
• has entry in NEXT_CHANGELOG.md file

Notes

• No documentation changes needed. This is a bug fix with no new fields or behavioral changes to document.